In the field of rendering grid data, 2D grids have traditionally been rendered as lighted surfaces in three-dimensional (3D) views. The same techniques have been used to render 2D grids in 2D views by treating the 2D view as a 3D view with a fixed view point. These conventional techniques impose memory and processing speed requirements that make it difficult, if not impossible, to render and manipulate large grids at interactive speeds as demonstrated below.
The rendering of 2D grids in 3D views is usually done by using an infinite light source to light a mesh of quads with normal vectors specified at the vertices of the quads. The quad meshes and normals are then processed by the fixed function graphics pipeline of the graphics card.
The mesh of quads is built using one of two methods—(a) by building quads whose vertices are at the bin locations of the 2D grid or (b) by subdividing the grid by two in each dimension and extending the grid by half a cell at the boundaries, interpolating the z values at the subdivided locations and then building quads centered at the bin locations of the sub-divided 2D grid.
Both methods result in a surface whose z value at the x,y coordinates of a bin location matches the value of the grid at that bin location.
The first method uses less memory but a major disadvantage is that points in the grid that do not have a sufficient number of neighbors will not get rendered. This is problematic for sparse grids such as horizons of a 3D survey that have been interpreted every other line. As a result, the second method is currently the preferred method.
For a fully populated m×m grid, the first method will result in close to m2 quads whereas the second method results in 4m2 quads. Assuming that the quad meshes are indexed quad meshes this would result in close to 2m2 vertices for the first method and 8m2 quads for the second method. Each vertex requires three 3 floating point values for the corresponding x, y and z coordinates and three 3 floating point values for the three components of the normal at that vertex. Assuming single precision, this results in 24 bytes for each vertex. The first method would therefore, end up requiring 48m2 bytes and the second method 192m2 bytes. For a 10000×10000 3D survey, a single horizon would require more than 19 Gigabytes of storage for the second method, which exceeds the capacity available in even the highest end graphics cards available today. Apart from the memory required, the processing time required to build the surface mesh and to calculate normals increases the amount of time before the image is rendered and can be displayed for conventional hill shading.
The geometry of the quad mesh and the normals at the vertices are used to compute the lighted colors at the vertices. The lighted colors are interpolated within the quads. The geometry is also used to perform a hidden surface computation, which is not really a consideration for map views because the 2D grid is viewed in a direction in which the grid is single valued along the z-axis. Nevertheless, the computation of the lighted colors at the vertices is still required and takes up significant memory.